Subject: Response to Peter Binninger's Comments

From: "John E. Fetvedt (tie 444-4366)" <[email-masked]>
Date: Mon, 14 Jun 93 08:02:28 EDT

Peter,

     Thank you for your comments on the CIW OSI TP SIG's proposal for
enhancements for CPI-C OSI TP support.

     The CIW OSI TP SIG discussed your comments and agreed on the
positions identified below. The SIG's comments are included in your
message and identified by "===>".

     Cheers.

John Fetvedt
CIW OSI TP SIG coordinator

----------------------------- Referenced Note ---------------------------

Received: from ibmstandards.cary.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R2)
   with TCP; Thu, 03 Jun 93 08:13:35 EDT
Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.35.17.2] with SMTP
    id AA144225 (for @vnet.ibm.com:nsaecho@ralvm6, from
[email-masked]/[email-masked]); Thu, 3 Jun 93 08:07:04 -0400
From: [email-masked]
Received: from snimucgw.stm.mchp.sni.de by thoth.mchp.sni.de with SMTP id AA26569
  (5.65c/IDA-1.4.4 for <[email-masked]>); Thu, 3 Jun 1993 14:10:46
+0200
Received: from d018s100.stm.mchp.sni.de ([139.22.108.23]) by snimucgw.stm.mchp.sni.de with SMTP
id AA23416
  (5.65c/IDA-1.4.4/ST.MCHP.SNI.DE for <ciw-sig-osi-tp%ibmstandards.cary.ibm.com@snimucgw>);
Thu, 3 Jun 1993 14:10:44 +0200
Received: from d018s100.stm.mchp.sni.de by d018s100.stm.mchp.sni.de
      at Thu, 3 Jun 93 14:09:31  +0100 (5.52.1/SIE-1.1)
Message-Id: <[email-masked]>
Date: Thu, 3 Jun 93 14:09:31  +0100
Apparently-To: [email-masked]
Apparently-To: <NSAECHO@ralvm6>
Apparently-To: <[email-masked]>
Apparently-To: <LIN@ROMEPPC>
Apparently-To: <BAINBRA@winvmd>
Apparently-To: <CHUNGHUY@ralvm6>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <[email-masked]>
Apparently-To: <LAI@stlvm1>
Apparently-To: <[email-masked]>
Apparently-To: <MITCH1@ralvmg>
Apparently-To: <[email-masked]>

My comments to osi-prop.ps

In general:

    In the X/Open Peer-to-Peer Specification Chapter 7
    a Starter Set is defined. CPI-C also defines a starter set.
    But there is an important difference:

    In P2P it is possible to work only with the starter set functions,
    if the functional unit commit is selected.
    In CPI-C this is not possible. The program must use Set_Sync_Level.

    Therefore I make the following proposal:

    If CPI-C is used together with TX and tx_begin is called,
    the default value for Sync_Level should be CM_SYNC_POINT_NO_CONFIRM.

===> The SIG rejected this suggestion. We believe that default values
===> should be stable and not depend on the order of calls or
===> interactions with some other interface.

Page 4, Text point 4:

    Do we really need basic conversation in OSI TP protocol stack?
    Existing basic conversation programs basing on LU6.2 can
    not be simply ported to OSI TP because of 2 reasons:

        a)  Set_Conversation_Type is needed at the remote application.
        b)  Basic conversation LU6.2 programs can use the second part
         of the LLID field of GDS header to transport user data.
         This is not possible in OSI TP.

    So i suggest not to allow basic conversation in OSI TP environment.

===> The SIG rejected this suggestion. We believe that both mapped and
===> basic conversations are useful and that the current proposal handles
===> both in a reasonable manner.

Page 4, Text point 6a:

    The proposed solution makes it impossible to write portable
    programs (i.e. programs that can be ported from LU6.2 to OSI TP),
    if the call Set_Partner_LU_Name is used.

    In LU6.2 environment the program has to use Set_Partner_LU_Name.
    In OSI TP environment the program has to use Set_AP_Title.

    I make the following proposal:
    In OSI TP environment the Set_Partner_LU_Name is interpreted
    as a Set_AP_Title call with ap_title_format = CM_AP_DN.

    I know, this is no beautiful solution, but it allows to write
    portable programs.

===> The SIG rejected this suggestion. What you suggest can best be
===> implemented as a product unique enhancement without including it
===> in the architecture.

Page 16, Text point 37c:

    The restriction that the value CM_ALLOCATE_CONFIRMED can
    only occur if sync_level has one of the values CM_SYNC_POINT
    or CM_SYNC_POINT_NO_CONFIRM may be wrong.

    For example the restriction does not exist at the Send_Data call
    (see page 17, text point 39).

===> The SIG accepted your correction and agreed to correct the proposal.

Page 27, first sentence:

    It is said that CMEAEQ extracts the own application-entity
    qualifier. This may me wrong, since on page 65 it is said
    that CMEAEQ extracts the Initiating-AE-Qualifier.

===> The SIG accepted your correction and agreed to correct the proposal.

Page 57, table 3:

    I think CMCANC should also be mapped to TP-BEGIN-DIALOGUE rsp
    (result=rejected) if this is the first activity on the conversation
    following Accept or Accept_Incoming and allocate_confirm =
    CM_ALLOCATE_NO_CONFIRM.

===> The SIG accepted your correction and agreed to correct the proposal.